Medical device wireless adapter

ABSTRACT

The invention relates generally to a medical device wireless adapter, and more particularly, to a module that adapts an existing legacy or newly designed medical device to a healthcare provider&#39;s wireless infrastructure.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. Provisional PatentApplication Ser. No. 60/750,202, filed Dec. 14, 2005.

FIELD OF THE INVENTION

This invention relates generally to a medical device wireless adapter,and more particularly, to a module that adapts an existing legacy ornewly designed medical device to a healthcare provider's wirelessinfrastructure.

BACKGROUND OF THE INVENTION

A broad range of existing and newly developed medical devices have aneed for wireless connectivity. Such medical devices range from complexmedical instrumentation incorporating embedded computers, includingpatient diagnostic equipment and patient monitors, to so-called “dumb”instruments that are network-unaware, such as a simple electronicthermometer with a serial output port that might do little more thanmake one type of measurement and output digital data representing themeasurement.

The WiFi (Wireless-Fidelity) Alliance is an industry consortium thatfollows the IEEE 802.11 series of standards and works to improveinteroperability between different suppliers. WiFi branded devices havebecome very popular and these devices are widely available. Connectionor access points are also numerous, especially in more populated areas.Because of the proliferation of 802.11 computing devices, where physicalproximity is not a barrier to network access, security is a concern.Encryption is one aspect of secure wireless operation. Wired EquivalentPrivacy (WEP), the first type of 802.11 encryption, was defeatedrelatively quickly. WEP serves as an example of the potentialvulnerability of wireless networks. TKIP and 802.11i (branded as WiFiProtected Access (WPA) and WPA2, respectively) have replaced WEP and arethe standard encryption solutions in use today.

Medical 802.11 users must further comply with security requirements ofthe Health Information Portability and Accountability Act of 1996(HIPAA). HIPAA mandates that healthcare providers take reasonablemeasures to maintain an environment and infrastructure where patientmedical information is only disclosed to those people and entities thathave a valid need to access this information. Accordingly, healthcareproviders expect medical device manufacturers to provide medicalinstrumentation that operates within a healthcare infrastructure in asecure manner, without an unreasonable configuration and maintenanceoverhead.

As the HIPAA guidelines are being implemented, the Industrial,Scientific, and Medical (ISM) 802.11 radio band market has transitionedfrom an “early adopter” phase in circa 2000 to a stage where WiFinetworks are commonly available. While adoption of these networkstandards has been widely viewed as successful and deployments are widespread (including healthcare institutions), initial mechanisms providedby these standards for managing a secure network have been proven to bevulnerable. The Institute of Electrical and Electronics Engineers (IEEE)and other organizations have responded with a number of significantimprovements. Their efforts have produced a new set of standards forwireless authentication and encryption, which have benefited fromextensive review and involvement by the cryptography community. Thiswork has resulted in a two stage release, with TKIP (WPA) firstaddressing improved authentication and key exchange in legacy wirelesshardware, and 802.11i (WPA2) providing full strength AES encryption,strong authentication, and highly robust key exchange protocols thatprovide even stronger security for new hardware designs. Legacy devices,as used herein, refer to medical, industrial, or scientific devices thatdo not have means for wirelessly connecting to a network and/or devicesthat do not support adequate authentication/encryption levels.

WPA and WPA2 take advantage of Public Key Cryptography, and provide arobust solution to the security problem. However, commercial productsthat implement these standards rely on the host processor in a PDA,laptop or desktop computer to implement the computationally intensivePublic Key portions of these standards. When these products are appliedto the types of Medical Devices introduced above, this places anenormous computational burden on a real-time processor that is generallynot well suited to the task. While chip manufacturers typically developdrivers and supplicants for common operating systems andmicroprocessors, these are generally not available for embeddedplatforms. Porting this sizable set of functionality to a broad range ofprocessors and real-time operating systems (RTOS) for a diverse set ofmedical devices presents a significant development and computationalburden that impacts each of the products that need wirelessconnectivity. While modern object oriented design practices do helpalleviate the development burden, porting code is still a manualprocess. Many of these legacy medical devices simply do not have the CPUor memory resources necessary to accommodate Public Key Cryptography. Inthe case of a network-unaware medical instrument, there are likely noavailable computational resources within the medical device to assist inany aspect of wireless connectivity. What is needed is a medical WiFiadapter that can accomplish authentication, key negotiation, certificatemanagement and strong encryption without the involvement of a hostcomputer or host medical device processor and without needing anexternal software library, such as a dynamic linked library (DLL),resident outside of the medical WiFi adapter related to theauthentication, key negotiation, or certificate management functions.

Bi-directional authentication of a device using Certificates can protectboth the device and the infrastructure from adversaries. What is neededis a robust bidirectional authentication system for use by medicaldevices on a WiFi healthcare network infrastructure. Since somehealthcare infrastructures support only unidirectional authentication(verifying to the network that the device is allowed, but the devicecan't determine whether it is connected to an imposter network or thereal network), what is also needed is a bi-directional authenticationcapable WiFi medical device wireless adapter that can also supportunidirectional authentication. Configuring medical devices on a medicalnetwork, particularly if authentication is used, can be a daunting andtime consuming process as every device must be manually configured.Therefore, what is also needed is a WiFi medical device wireless adapterthat can manage available certificates and automatically present aseries of certificates to an authentication server in an order in whichthey are most likely to be accepted. Even if many clients use strongauthentication and encrytion, when some client devices do not,unauthorized devices may access the network, leaving it vulnerableunless the network is careful designed.

Another problem in adding a network-unaware medical device to a medicalnetwork involves defining the instrument and its control and measurementparameters and presenting them in a meaningful way to the medicalnetwork. What is needed is a medical WiFi adapter that can assign aunique identifier to each network-unaware medical device or instrumentadded to a medical network to give context to the wirelesscommunications with each network-unaware device.

Another problem in adding wireless connectivity to a medical device ispower consumption. Typical WiFi devices (including cards, boards, andmodules), such as those available for laptops, involve a great deal oftraffic while a user is interacting with a computer, surrounded by longperiods of no activity. To conserve energy, users may disable thewireless interface. Even without this, laptop and PDA users can workwithin a process where the battery is charged every few hours. Medicaldevices operate with a completely different set of use models. Forexample, in one common medical device mode, the medical device needs tosend relatively small packets of data to the network continuously, hourafter hour, day after day without tying the patient to a power cordumbilical. WiFi products that have been developed for the laptop andgeneral purpose computer market lack the power options needed for thetypical modes of operation used by wireless medical devices and do notsupport the complexities of state of the art medical-grade wirelessdevices and networks. What is needed is a WiFi medical device wirelessadapter that can support power options needed for the typical modes ofoperation of medical devices.

Another problem with commercial WiFi products is personal radiofrequency (RF) safety. While there is no credible or definitive evidenceto date regarding any cancer or similar human pathology caused by RFexposure, it is well known and accepted that radiated RF energy ofsufficient power and duration can heat human tissue. In response to theintense interest of recent years generated by studies involving cellphones and human exposure to RF, the FCC has set standards for maximumexposure to REF. The FCC defines the quantity used to measure how muchRF energy is actually absorbed in a body as the Specific Absorption Rate(SAR), expressed in units of watts per kilogram (W/kg) or milliwatts pergram (mW/g) for portable devices (used within 20 cm of the body).Commercial WiFi devices are designed for mobile products and thereforesubject to the much less stringent Maximum Permissible Exposure (MPE)limits. Thus commercial 802.11 devices set their output RF power andduty cycle (ratio of transmit time to non-transmit time) based oncommunications performance parameters and requirements, generallyignoring SAR (and MPE) limits. A medical WiFi adapter might be used inconjunction with a medical device situated very close to a patient. If aWiFi device were to be situated very close to a human body for extendedperiods of time, it is possible that the RF power and/or the duty cycleof the WiFi device would need to be reduced to meet the FCC SARrequirements in such a way as to not impact the operation of the medicaldevice. Therefore what is needed is a medical WiFi adapter that canavoid exceeding the FCC SAR limit, while not adversely impacting theoperation of the medical device, even when situated or worn very closeto a patient's body.

There currently exist methods to track the physical location of anactively communicating commercial WiFi device. However, these methodsrequire ongoing communications operations of the commercial WiFi deviceand if the commercial WiFi device is set to a power save mode where thetransceiver is inactive, tracking ceases. There also exist WiFi locationtags, also know as asset tags or location beacons that can operate atlow power or go to standby and periodically send out a short WiFicommunication solely for the purposes of radio tracking. What is neededis a medical WiFi adapter having a plurality of operating modes that canoperate both during active WiFi data communications and when the medicalWiFi adapter is in a power saving state. What is further needed is amedical WiFi adapter that can continue to provide a tracking functioneven when the power is removed from any host medical device or computerto which it is attached.

Most commercially available WiFi devices include one antenna permanentlyaffixed to the device, usually in the form of an antenna extension on aplug in WiFi computer card. At least one specialty WiFi device offers anantenna “pig tail”, a short length of shielded RF cable with a connectorto receive a cable from a WiFi antenna. However, what is needed is amedical WiFi adapter with two or more diversity antenna connectionswhere the antennas can be located apart from each other and the antennascan be operated one at a time to aid in signal acquisition and assetlocation by RF beacon tracking.

There also exist medical device and monitor communication systems usinginfrared (IR), optical, and RF connectivity independent of WiFi. Onefeature provided by an IR communication system is the ability topositively locate a network resource to a particular room or todetermine what side of a wall it is on by use of line of sight opticalnetwork communication. What is needed is a medical WiFi adapter that canconnect to another medical network to improve location and trackingaccuracy over that location accuracy available in WiFi only networks.What is also needed is a medical WiFi adapter that can connect toanother medical network to provide a backup route for the transmissionof critical care data.

Yet another problem with commercially available WiFi devices isreliability. Generally the communication lines of these devices(including signal, data, and control lines) lack filtering to protectthem from radio frequency interference (RFI) or electromagneticinterference (EMI). A static discharge or other interfering signal cancause most WiFi devices to do an uncommanded reset. Therefore there is aneed for a medical WiFi adapter that is RFI/EMI hardened.

A related problem with commercial WiFi devices is that these devices canhang or freeze in operation. The only way to clear this fault is toreboot the WiFi device, which usually means rebooting the host processor(usually a laptop or other general purpose computer) as well. It is notpractical to reboot most patient care and monitoring devices while theyare in patient service. In fact, a medical device reboot could bedangerous or life threatening to the patient in the case of somecritical care medical devices. Therefore there is also a need for amedical WiFi adapter that does not freeze, or in the unlikely event of ahang, that can reboot independently of and without rebooting any medicaldevices for which it is providing wireless connectivity, as well asrestore its previous working configuration or alert the host device thata re-configuration is required.

Yet another problem for a commercial WiFi device is to reestablish itsnetwork association after a reset. Once reset, a typical WiFi devicetakes on factory defaults and needs to be re-configured for a givenwireless network. While the host can re-configure the card upon reset,it is faster if the card has all the information required to configureitself upon reset. Therefore there is also a need for a medical WiFiadapter that can save its most current operating configurationparameters, reboot as needed, and quickly and automatically re-associatewith its intended network.

Yet another problem for commercial WiFi devices involves updating theconfiguration and firmware within the device. Some commercial WiFidevices can be firmware updated by use of the host computer as bydownloading a firmware update from a WiFi device manufacturer and thenupdating the firm-ware by executing a small program resident on the hostcomputer over the host computer bus, such as a PCI bus. The problem isthat in a typical medical environment the host processor might only beminimally involved in WiFi operation and not able to conveniently accept(as by download) and then update its attached (or otherwise installed)medical WiFi adapter. Moreover, some medical WiFi adapters might nothave an available host processor to assist in performing softwareupdates. Medical devices typically lack a interface for configurationand further lack a means of remotely configuring the medical device.Therefore there is also a need for a medical WiFi adapter that canindependently receive firmware updates over a WiFi connection withoutendangering a patient critical care function. Further, there is a needfor a medical WiFi adapter that can receive a firmware update for andupdate the firmware in a host medical device over WiFi withoutendangering a patient critical care function. What is needed is amedical WiFi adapter that can also provide network applications such asa TFTP, SNMP, or HTTP.

Another problem in medical device applications is that a very largenumber of medical monitors, instruments, and network-unaware devices canbe spread out over a large building or complex of buildings and overmany floors of the buildings. Therefore what is needed is a medical WiFiadapter that can take on additional networking roles to facilitatemedical WiFi applications in the medical business environment, includingbridging between different network types or acting as gateway for a PANto connect to an IP network, where any additional network functions canbe time multiplexed or otherwise time shared if there are any on goingor intermittent WiFi client operations, and in a way so as not tojeopardize any critical patient WiFi communications.

Another problem is that commercially available WiFi devices are not wellsuited to handling input and output (I/O) to or from any port or busother than the port or bus to which the WiFi device is attached. A smallnumber of specialty WiFi devices have offered additional inputs, such asfrom a serial communications connection. What is needed is a medicalWiFi adapter that can accept (I/O) from a plurality of I/O connectionsin addition to any host bus to which the WiFi medical adapter might beconnected, including one or more serial connections, USB connections,802.3 Ethernet connections and/or a connection to a parallel interfacesuch as card bus, compact flash, or PCMCIA bus.

What is further needed is a system to support efficient 802.11communication for different classes of information between the pluralityof medical devices and the network. Also needed is a system toprioritize the data so as not to delay time critical diagnostic ormonitoring data in presence of non-critical data.

Where a plurality of medical devices is connected to a medicalmeasurements with an individual patient. The collated measurements canbe reported or continuously displayed for a nurse or doctor to viewthem. The nurse or doctor can form a diagnosis or recognize a criticalpatient situation that might need short term attention or an emergencyresponse. What is needed is a medical WiFi adapter that can also run oneor more diagnostic algorithms accepting input from a plurality ofmedical devices to take some action such as sounding an alarm to assista medical professional to quickly identify a patient in medicaldistress.

There exist a number of United States patents directed to medical deviceadapters and modules, including U.S. Pat. No. 7,129,836 issued to Lawsonet. al. on Oct. 31, 2006. Lawson teaches a wireless patient dataacquisition system. Particularly, Lawson teaches an acquisition devicethat includes inputs to receive data from sensors connected to apatient, a wireless and/or wired transmitter that transmits the datareceived by the inputs, and a housing. Lawson's device can be furtherconfigured to transmit data from a data acquisitions device to a localmonitor point-to-point. Lawson does not teach a medical adapter than canbe controlled by a host acquisition device, nor does Lawson teach amedical adaptor that converts a non-wireless medical device to awireless medical device, nor does Lawson teach a medical adapter in asmall form such as a PCMCIA, PCI, Compact Flash or 802.11 a/b/g networkinterface card. Lawson is hereby incorporated by reference in itsentirety.

U.S. Pat. No. 6,950,859 issued to Bartek et. al. on Sep. 27, 2005teaches a method for emulating a physical connection using a wirelessconnection. Bartek further teaches an adapter with an RF interface, aprocessor, and a USB interface. Bartek does not teach an adapter capableof transmitting data wirelessly to a network, such as a healthcareprovider's wireless infrastructure. Similarly, U.S. Pat. No. 6,850,788issued to Al-Ali on Feb. 1, 2005 teaches a sensor and monitor interfacedevice, allowing a monitor to wirelessly receive data from a sensor.Like Bartek, however, Al-Ali does not teach an adapter that is capableof transmitting the data to a health care provider's wirelessinfrastructure. Bartek and Al-Ali are hereby incorporated by referencein their entirety.

U.S. Pat. No. 3,810,102 issued to Parks, III et. al. on May 7, 1974teaches a method and system for transmitting biomedical data to a remotestation for subsequent processing. The system samples and digitizesanalog electrical biomedical signals over a communication link. ParksII, however, does not teach a medical adapter that includes abi-directional wireless radio transceiver. Bi-directional transmissionallow for a feedback to inform the transmitter if a re-transmission isrequired, resulting in a more reliable communication link. It alsoallows the network to control the instrument and/or the wirelesscommunication link via the wireless communication link. Parks III ishereby incorporated by reference in its entirety.

Therefore, a medical device wireless adapter that is backwardscompatible with existing legacy devices an-d forward compatible withemerging standards, including bi-directional communication is desired.

Further, a medical device wireless adapter that is usable with embeddedmedical applications and that is also low power, a robust wirelesssolution with failure recovery, HIPAA compliant, and support for devicelocation is desired.

SUMMARY OF THE INVENTION

The invention comprises, in one form thereof, a medical device wirelessadapter (“MDWA”) that adapts an existing legacy or newly designedmedical data acquisition (“host”) device to a healthcare provider'swireless infrastructure.

More particularly, the invention includes a medical device wirelessadapter comprising a radio section; one or more means for exchangingdata between said adapter and said host device; one or more means forexchanging data between said adapter and a network; a CPU blockincluding integrated support for hosting one or more applications; andone or more memory means; wherein said adapter is configured with one ormore host interface modes.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is disclosed with reference to the accompanyingdrawings, wherein:

FIG. 1A is a block diagram of a medical device wireless adapteraccording to the present invention;

FIG. 1B is a block diagram of a medical device wireless adapter with asingle CPU running both the application code and the MAC/BB code;

FIG. 2 shows a block diagram of an exemplary medical networkinfrastructure;

FIG. 3 is a power mode state transition diagram for an exemplary MDWA;

FIG. 4 shows a block diagram of an exemplary MDWA in greater detail; and

FIG. 5 shows an exemplary communication line filter.

Corresponding reference characters indicate corresponding partsthroughout the several views. The examples set out herein illustrateseveral embodiments of the invention but should not be construed aslimiting the scope of the invention in any manner.

DETAILED DESCRIPTION

Referring to FIG. 1A, there is shown a block diagram of a medical devicewireless adapter (“MDWA”) of the present invention. In one embodiment,the MDWA 100 can connect to and exchange data over a PCMCIA bus 102.This is a particularly convenient way to add wireless connectivity tolegacy medical devices having available PCMCIA slots to accept a MDWA100 in this embodiment, in the form of a PCMCIA card. CPU block 101(including internal and/or external memory) performs all applicationcomputational functions of MDWA 100. MDWA 100 can receive and send datato devices over one or more serial ports 103, Ethernet ports 104, USBports 105, over the PCMCIA bus, or over other interface known to thoseskilled in the art, including PCI, CardBus, SPI, IEEE 1394 and I²C.Manufacturing interface 106 can be used to program the Application CPUand associated memory 101 with the MDWA firmware at time of manufactureor in the field via an interface cable (not shown). JTAG block 109represents self test routines that enhance the manufacturing yield ofMDWA 100 by thoroughly exercising many of its functions during power upor by other request for self test, including boundary scan. These testroutines can follow guidelines or standards set forth by the Joint TestAction Group (JTAG). The radio section 110 (typically including aMAC-baseband processor 123 and a Radio Frequency (RF) transceiver 124)can comprise a commercially available WiFi RF chip set. FIG. 1B shows anMDWA with the logical function of the application CPU with memory andthe MAC/BB processor embodied in a single chip 125. Returning to FIG.1A, radio section 110 can be further connected to CPU block 101 by theinterface bus 112, such as Compact Flash, PCI, SPI, or other bus knownto those skilled in the art. Cable 121 and connector 120 can be used toconnect an antenna 111A to RF section 110. If optional diversity switch122 is included, a second antenna, 111B, may be connected, whereupon theMAC/BB processor implements an algorithm to select the best antenna touse via diversity switch 122. Power management block 108 controls andsets the various power modes of MDWA 100. An optional connection to asecondary communication system (auxiliary device) 107 can add backupcommunication and supplementary location tracking functionality.

MDWA 100 can be a module, board, or plug in device. MDWA 100 can be usedto adapt an existing legacy or newly designed medical device(collectively, “Host Devices”) to a healthcare provider's 802.11 a/b/gwireless infrastructure. As used herein, “Host Device” refers to anymedical device configured to acquire patient data. Alternately, the MDWA100 can be used to adapt a medical device to a healthcare provider's802.3 hardwired Ethernet infrastructure. MDWA 100 can provide a numberof capabilities, described below, that are not available from any of thecommercially available 802.11 a/b/g network interface cards. MDWA 100can also be suitable for use with Body Area Networks, Personal AreaNetworks, Wide Area Networks, Metropolitan Area Networks, Cellularnetworks and other networks known to those skilled in the art. Forexample, a Serial-to-Bluetooth adapter such as the SMK VRB2211 could beattached to the serial interface 103, allowing MDWA 100 to communicatewith a host device over a short-range wireless link as is taught in U.S.patent application Ser. Nos. 10/806,770, 11/031,736, 11/455,368, and11/455,329, entitled “Personal Status Physiological Monitor System andArchitecture,” to Welch, et al., the entire contents of each hereinincorporated by reference.

Each MDWA 100 can have a unique MAC address for the Wireless interface,and a unique MAC address for the hardwired Ethernet interface. Theseaddresses can be programmable via manufacturing interface 106. MDWA 100can also have a Product Serial Number. The serial number can beconfigured on manufacturing interface 106 and readable via any MDWA 100interface including interfaces 102, 103, 104, 105, or 106. MDWA 100 canbe calibrated digitally and the calibration constants can be read &verified. Note that all functions of the manufacturing interface can beavailable over any interface, but in the preferred embodiment,manufacturer-specific functions are typically restricted.

Serial port 103 can support RX and TX signals using, for example,bipolar RS-232 signaling levels or TTL-level signals and power can besupplied over the same interface, allowing serial devices to providepower to the radio card analogous to the method used in PCMCIAinterfaces. A Power/Serial port 103 can also support handshaking signalssuch as RTS, CTS, DTR, and DSR signals using either TTL or bipolarRS-232 signaling levels. The RTS/CTS signals can be included for devicesthat require hardware flow control. The DTR/DSR signals can be includedin consideration for a device that asserts a signal to indicate it isready to communicate and/or support an “On Network” indication, e.g. anLED, on the Host Device without a need for software support by the HostDevice. It should be noted that any Power/Serial port input signal canalso be used to “wake” MDWA 100 from a low power mode.

In one embodiment, the MDWA 100 operates in complex WiFiimplementations, especially including IEEE 802.1x and 802.11i, whichsupport authentication, session key negotiation, certificate management,and encryption down into the MDWA. MDWA 100 can also implement 802.11equality of service and is upgradeable without support from the hostdevice to support other standards such as improved roaming support(802.11r and 802.11k) as these standards are ratified. MDWA 100 canperform these functions, freeing the Host Device both in terms ofcompute resources as well as software complexity. Note that use of acommercial off the shelf wireless card would push much of thisimplementation into the device driver, or DLL, and as a result onto thehost processor. While such a sharing of computational resources can beacceptable where the host is a Windows laptop with a 1-2 GHz processorand no real-time constraints, it is not a desirable solution for a hostmedical instrument, such as a Vital Signs Monitor.

By way of example, there are at least two methods in which the MDWA canbe used to interface with a Host Device. The first method comprises aHost API Mode, in which the Host Device integrates a small set of codeknown as the Host Applications Programming Interface (API), or Host APIProxy, which allows the Host Device to manage and control the MDWAthrough an applications interface. The second method utilizes an AdapterMode, in which the Host Device does not integrate any code, and operatesin the manner it was originally designed, e.g. simply transmits raw dataon a serial port. In this mode, the MDWA can detect that a device isready to establish communications with a serial device, e.g. termserver, and adapt that protocol to allow the device to establishcommunications. The MDWA does this by monitoring the data and/or controllines of the appropriate interface, and then acts on behalf of thedevice to present said device to the network. Once device communicationshas been established and completed, as by a proprietary rendezvous orsimilar discovery protocol, the MDWA becomes a simple pass throughdevice, forwarding packets between two interfaces. The rendezvousprotocol is described in greater detail in co-pending and commonly owedU.S. Pat. No. 6,616,606, “Patient Monitoring System,” the entirecontents of which are incorporated herein by reference. Data trafficand/or control line status can also be used in this mode to detect thata connection should be timed out, and the process restarted.

Host API Mode

In one embodiment, the MDWA provides a single, common Host ApplicationProgram Interface (API) regardless of which interface is used by a givenHost Device (Serial Port, PCMCIA, USB, or other alternatives). Completefunctionality can be provided over all of the available interfaces. Thiscommon API encourages reuse of software components across multipleproduct lines, further reducing the effort to integrate the MDWA withsubsequent devices.

In one embodiment, the Host API Proxy can be a small set of code that tobe multiplexed with other network data traffic, and sent to or receivedfrom the MDWA over the appropriate interface. Unlike modems and someprior art devices, which share a single channel for network data andcontrol information, this proxy can communicate over a set of distinctlogical channels that coexist concurrently with the control channel usedto manage the MDWA.

The code can also encapsulate the process of creating packets to bemultiplexed over the appropriate interface (RS-232, PCMCIA, Ethernet,USB, or other interface), destined for either the command interpreter ora specific socket endpoint. In one embodiment, the MDWA providesdeterministic behavior with respect to command traffic and data trafficthat is multiplexed onto the serial port or other interface. Note thatsome serial interface devices, such as modems, transition a singleserial connection between command mode and data mode when a connectionor attachment is made with the other end of the network. While an escapesequence or control signal marks these transitions, in many cases it isimpossible for the host device to tell whether the serial port was incommand mode or data mode at the instant the last command or data packetwas sent. The MDWA software is adapted to address this problem throughthe use of a multiplexing layer, which can identify and route to severallogical destinations, independent of the state of the otherdestinations. The use of a multiplexing layer enables multiple networkendpoints to be active at the same time, regardless of the type ofinterface. Some medical device protocols require that two distinct portsbe open at the same time, e.g., one for the rendezvous packets, and onefor instrument data packets. As a result, the Host Device needs to beable to send and receive data for at least two different ports, pluscommands for the MDWA over a common channel. This channel can be anyavailable host interface, e.g., USB, Ethernet, Serial, PCMCIA, CardBus,Mini-PCI, and others generally known to those skilled in the art.

For example, when using interfaces such as PCMCIA and Ethernet, onecould simply assign these functions to different port addresses. In oneembodiment, the MDWA is adapted to send/receive data to/from multipleendpoints over a common channel, allowing fully capable wireless adapterfunctionality over less capable interfaces such as RS-232. The Host APTProxy provides a proxy for network communications using an objectoriented C++ API styled after BSD Sockets. Examples of this can be foundin the Java and C# socket APIs.

Adapter Mode

Adapter Mode provides the wireless adapter the ability to adaptso-called “dumb” host devices, such as a legacy Infusion Pump or othernetwork-unaware devices. These adapted devices can then communicate withat least one central monitoring station, at least one server, or othercontrolling system product, and enable management and tracking of thosedevices by the IT network staff

In this context, the Host Device does not integrate the Host API Proxy.Rather, the MDWA actively presents the Host Device to the network. TheMDWA is further adapted to execute rendezvous or discovery medicalprotocols on behalf of the attached Host Device. In this embodiment, theprotocol can comprise a UDP packet of a pre-defined format that isbroadcast to the network on a well known port This broadcast packet caninclude a unique device identifier that is a requirement for networkedsystem products, even where the legacy device does not provide thiscapability. The unique identifier may be configured into the MDWA,either during provisioning or during customer configuration on sitethrough a web or command line interface.

Once the initial rendezvous or discovery process is complete, the MDWApasses bidirectional data between the device and the networked system.This enables even a network-unaware device with only an RS-232 serialport or USB port and no network stack or other supplemental software tobecome a “Full Network Citizen,” with minimal or no modification to theexisting device.

In this embodiment, the MDWA also automatically enables a networkconnection by completing the steps of association, obtaining an IPaddress, and authenticating. Furthermore, an application on the MDWA mayprovide the bridging of the communications data between the nativedevice and the TCP/IP network interfaces.

In another embodiment, the MDWA communicates with the Network Host witheither a real-time rendezvous or a store and forward mechanism, such ase-mail or pager notification. For real-time rendezvous, a pre-definedpacket is transmitted as either a broadcast or directed packet to aserver in order to establish a link between the host device and theserver. In the case of store and forward, the MDWA buffers theinformation until it can be handed off to the destination, such as ane-mail or paging service. Initiation of either of these communicationmethods can occur upon assertion of a control line, or upon receipt of apacket the host normally sends to communicate with another RS-232device. In a further embodiment, the MDWA Power Modes, includingHibernate, can be automatically controlled by the application running onthe MDWA, based on traffic analysis. MDWA Power Modes are discussed inmore detail herein.

In one embodiment, the manufacturing interface 106 supportsmanufacturing configuration of the call method. This defines the initialcontrol signal behavior, or the initial bytes that would betransmitted/received by the MDWA to begin communications with the HostDevice.

An MDWA 100 as so far described can be used as a part of the WirelessInfrastructure of a hospital or clinical office. FIG. 2 shows a blockdiagram of an exemplary medical network infrastructure 200.

The MDWA is configurable to address several different classes of HostDevices. The most “mission critical” of these devices are those thatmust communicate adverse patient conditions, such as patient alarms fromcontinuous vital signs monitors 205, and equipment alerts from infusionpumps 204. Monitors 205 are typically attached to a single patient 209for hours or even days, and report alarms in addition to capturingvarious physiological variable data including, but not limited to, pulserate, and body temperature, as well as ECG, pulse oximetry, andadditionally periodic measurements of blood pressure as needed. Vitalsigns monitors typically include sensors or other electrodes foracquiring patient data. The MDWA is also configurable to address bodyworn sensors. An example of this type of host device is morespecifically described in copending U.S. patent application Ser. No.11/591,619 entitled “Body Worn Physiological Sensor Device Having aDisposable Electrode Module,” to Baker, et. al., filed Nov. 1, 2006, theentire contents of which are incorporated herein by reference. Inaddition to monitors, several other types of devices can co-exist on anetwork. These include devices more fully described herein.

Spot Check Monitors 201 are devices that can typically travel with aNurse or Clinician 203, and are used to acquire and upload individualreadings while the clinician is present with a patient 209. Wirelessconnections in these devices allows the patient data to be transacteddirectly to the Clinical Information System (CIS) or HospitalInformation System (HIS), via an interface such as HL7, which interfaceis implemented on the MDWA.

Infusion Pumps 204 are devices that can use a wireless network todownload Drug Libraries and Medication Rules, avoiding the need for abio-technician to track down and interact with each and every pump inthe hospital. Downloading Drug Libraries and Medication Rules is aidedby the MDWA that buffers the Libraries and Rules analogous to how itbuffers new firmware for the host device, as is taught later in thespecification In addition, prescriptions can be transferred over thewireless infrastructure to an infusion pump so that a clinician needonly confirm the order or the clinician input can be transferred overthe wireless infrastructure to the pharmacy and verified against theoriginal prescription order. While wireless infusion pumps exist, theydo not implement strong authentication/encryption and a bevy of legacyinfusion pumps are in use in hospitals today.

Personal Digital Assistants 202 are handheld devices that can be used bya clinician to record and/or receive clinical information, includingphysiological alarms, and interact with other systems in the hospital.

Mobile diagnostic workstations or Computer on Wheels (COWs) 208 are PCsthat can be used for clinical activities such as vital signs charting,CIS access, HIS access, and/or the ordering and accessing of ClinicalLab results such as by a hospital intranet 212. One specific applicationis described in U.S. patent application Ser. No. 11/131,015, “MobileMedical Workstation,” filed May 17, 2005, the entire contents of whichare incorporated herein by reference.

Network Access to the hospital intranet 212 can be provided by aconnection to a medical 802.11 wireless infrastructure 210 by MDWA 100and by other hospital devices. Guest network access is a capability thatallows patients and visitors 206 to use laptops 207 with wirelesscapability, such as a commercial general purpose 802.11 adapter 214, toaccess the Internet 211 while they are in the hospital.

For medical devices and instruments that provide Continuous Vital SignsMonitoring, there is an increased expectation of system reliability,including the need for a high reliability 802.11 medical networkconnection. By contrast, at a slightly less demanding level ofreliability, Spot Check devices can use whatever network is available(including wireless infrastructure 210), whether or not it meets themission critical requirements,

FIG. 4 shows a more detailed block diagram of exemplary MDWA hardwareaccording to the invention that has been found useful to test thevarious functions of a MDWA as described herein. The CPU and some memoryfunction of 101 in FIG. 1 were provided by an AT91RM9200 4001manufactured by the Atmel Corporation. The AT91RM9200 includes a 200MIPS ARM920T processor with 16K-byte instruction and 16K-byte data cachememories, 16K bytes of SRAM, 128K bytes of ROM, External Bus Interfacefeaturing SDRAM, Burst Flash and Static Memory Controllers, USB Deviceand Host Interfaces, Ethernet 10/100 BaseT MAC, Power ManagementController, Real Time Clock, System Timer, Synchronous Serial Controller6-channel Timer-Counter, 4-channel USART, Two-Wire Interface, SerialPeripheral Interface, Multimedia Card Interface and Parallel I/OController. The AT91 supports slow clock and idle modes that are used tosupport low-power operations discussed below. Additional memory asrepresented by block 101 of FIG. 1 was present as FLASH memory 4002 andSRAM memory 4003. Debugging was accomplished with the use of an EthernetDebug connection 4004 (connector not shown) and Serial Debug connection4005 (connector not shown). A radio section 110, comprised of a ConexantMAC/Baseband processor and transceiver (Voyager chipset) coupled toAT91RM9200 4001 via a CompactFlash Interface Bus 112. The power to radio110 is controlled by FET 4006, to support low-power modes discussedbelow. The PCMCIA interface 102 of FIG. 1 was provided by PCMCIAconnector 4007 and PCMCIA circuit interface by a Universal AsynchronousReceiver Transceiver (UART) 4008. The USB port interface 105 of FIG. 1was provided by USB connector 4022. Although not implemented in theexample, it is contemplated that any connector that would connect to thehost, including USB connector 4022 and Ethernet Debug connection 4004can also be coupled to hibernate circuit 4016, preferably coupled viaFiltering/Protection circuits 4020. A decision to couple an interface tothe hibernate circuit depends on the power used by that interface. Inthe present embodiment, only serial and PCMCIA physical host deviceinterfaces are supported, therefore Ethernet and USB are disabled tosave power. The serial port interface 103 of FIG. 1 was provided byserial/power connector 4009 and RS-232 level shifter 4010, allowingeither TTL or RS-232 level signaling. Timing and clocks for theAT91RM9200 4001 were supplied by 18 MHz crystal 4011 (CPU clock) and a32 kHz RTC (real time clock) Crystal 4012. MDWA power supplied by a 3.3Vregulated or 4 V to 6 V unregulated power source 4013 and regulated by a3.3 V regulator 4014 (if required) and a 1.8 V regulator 4015. Note thetopology of the regulatory circuits depends is optimized for bestefficiency and in some designs, the lower voltage regulator may rundirectly off the input power source. Hibernate circuit 4016 providedpart of the power mode control system. Filtering/Protection Circuitsblock 4020 comprises a filter to remove RFI/EMI signals that could causean uncommanded reset of application CPU 4001. It should be noted thatany communications (signal) line can also be advantageously filtered,including reset, data, and other signal lines. Watch dog circuit 4021provides an external monitoring circuit to detect and restart the modulein the event of a software application failure or operating systemfault. An auxiliary device such as a location hardware block such as ismanufactured by Radianse, Inc. of Lawrence, Mass. 4017 is supported tosupplement MDWA functionality. For example, optical communications block4019 can aid in locating an asset using the MDWA to tell for example,what side of a wall the asset is on (while RF energy from Radio 110 andRF block 4018 can penetrate a wall, the light from opticalcommunications block 4019 cannot penetrate an opaque wall). Further RFblock 4018 can provide backup data communications to the MDWA 802.11network connection. It should be noted that other public domain andproprietary hospital communication networks and channels can be added toan MDWA in addition to, or in place of the location/communication 4017function, or the MDWA can operate with no supplementarylocation/communication system.

Referring now to FIG. 5, filtering of data, signal, and control lines,such as a reset line, can be achieved using a low-pass filter, such asimplemented by the RC section (R 501, C 502) of the circuit 500. Inaddition, if ESD protection is required, diodes 503 to supply andgrounds may be used. Depending on data speeds and immunity levelsrequired, the capacitance of diodes 503 can serve to provide enoughlow-pass filtering to provide protection against signal glitches fromexternal sources.

The MDWA of the present invention typically supports IEEE standardsincluding 802.11a, 802.11b, and 802.11g PHYs, but can be extendedthrough firmware update to support 802.11n. To that end, a TCP/IP stackcan comprise a minimum of four layers, including frill support for UDP,TCP, ARP, DHCP, and ICMP. In addition, applications are included toprovide support for TFTP and web-based services. This MDWA can furtherprovide support for a rendezvous protocol, e.g., a predefined UDPbroadcast packet. Also, client support can be provided for DNS, NTP,SNMP, and other network protocols known to those skilled in the art.

The following is a summary of MDWA 100 wireless adapter functions thatcan be performed in firmware running on CPU block 101. We note thatRadio Section 110 includes a CPU and all aspects of Radio CPU can run onthe Application CPU 4001 and vice-versa. In a preferred embodiment, asingle CPU in on the radio card implements MAC/Baseband and applicationsfunctions.

Asset Tracking

An Asset Tracking and Real Time Location Service (RTLS) using MDWA 100can be done in at least two alternative technologies. The first is basedon a hybrid IR/RF capability that can be provided by a secondarycommunication system attached as exemplary auxiliary device 4017 and thesecond is based on 802.11 Access Points receiving and examining thesignal strength and/or latency of 802.11 packets. Note that some assettracking solutions support a minimal communication channel. An exemplaryback-up communications system could be set up using an AeroScout,Radianse, or PanGO module combined with an 802.11 infrastructure. An802.11 client can be tracked by the infrastructure to which it connects,as illustrated by thin AP solutions from Aruba Wireless Networks andCisco Networks, however, when that client goes off the air, trackingability is typically lost. Dedicated 802.11-based tracking tags such asthose offered by AeroScout or PanGO last for years, but work only on802.11b/g infrastructures and do not support full 802.11 clientcommunication. The MDWA can also provide uninterrupted trackingoperation, where the Asset Tracking function is provided even forperiods when the Host Device power has been turned off, or the mainbattery has been removed. The MDWA provides an auxiliary power inputwhere a backup power source 4023 provides sufficient energy for the MDWAto beacon as if it were only an asset tracking tag. That is, the MDWAcan be placed in a low-power state where it is programmed to provideasset tracking functions. Upon exit from this state, full 802.11 radiofunctions are restored. Tracking can continue based either only on802.11 data traffic, or 802.11 data traffic and transmissionsspecifically tailored for tracking, such as transmitting on everychannel periodically to ensure that all nearby APs contribute to theposition determination. To save power, the MDWA (or a simple assettracking tag) can occasionally determine which APs are nearby (e.g.using 802,11r or probe requests) and only transmit on those channels.Asset tracking can be used to track assets, patients, and personnel.Asset tracking makes it possible to find equipment and decreases thetime it takes to find wheelchairs, infusion pumps and other equipment.This enables the hospital to better manage their medical equipmentassets. An alarm can sound if equipment is removed from its approvedarea. Patient tracking allows a patient to be found quickly in the eventthat the patient has an event and also allows the hospital to managepatient flow to decrease wait time. Personnel tracking allows thehospital to send the nearest clinician when a patient is in trouble andallows the hospital to manage workflows so that clinicians arrive whenneeded, e.g., alert a surgeon so that the surgeon does not arrive beforethe surgical suite is ready, or before the patient has been prepped.

Converting to an Asset Tag

Any active 802.11 radio can be located by infrastructures such as thoseavailable from Cisco Systems and Aruba Networks. Similarly, asset tagscan be located through its periodic beacon, though these devices cannotmaintain a network connection. When an 802.11 radio is inactive,locating it becomes impossible unless it takes on the character of anasset tag, transmitting an occasional location beacon. This locationbeacon could be implemented by occasionally awakening and establishing anetwork connection or it could include full emulation of an asset tag,including beaconing that allows location detection without a fullnetwork connection (saving power compared with establishing a networkconnection). Modifying the number of beacons per unit time can bemodified to trade off battery life for how often the location isupdated, a feature that exists in asset tags, but not in radio cards. Inaddition, when the MDWA changes to asset tag mode, it can modify thetransmission power to trade off location accuracy with battery life(generally, the more APs that hear the device, the smaller the locationerror). The MDWA may move into asset tag mode when either primary poweris removed from the MDWA or the MDWA is placed into one of the low-powermodes. To save power, the MDWA may use a different Operating System whenoperating in beacon mode. When the MDWA has data to transact, itautomatically leaves low-power mode and the asset tag mode and entersfull 802.11 radio mode to support data transmission.

Adding Location to the Patient Context

Patient mobility is a well-known contributing factor to faster recoverytimes and wireless monitoring of patients has existed for many years,augmenting hard-wired (typically with more parameters) bed-sidemonitors, to provide for patient ambulation. When hard-wired patientsneed assistance, it is simple to determine their location. Some bedsidemonitors can run in wireless mode as the patient is transported and someportable monitors support multiple parameters, allowing their use onmore acute patients. What is missing is the risk mitigation for the usecase of when the ambulatory patient needs assistance and needs to befound—that is, adding location to the patient context. Patient contextis defined as the set of linked data that identify a patient or pertainto a patient. Items such as name, patient ID, current state ofphysiological parameters, alarm limits, the Monitor ID and locationtogether provide the patient context.

For location to be added to the patient context via the location of thepatient monitor, one must ensure that the monitor is not inadvertentlyswitched to another patient.

Once a clinician attached to a patient and configured with alarmsettings and the patient name, the monitor can detect when it losesphysical connection with the patient because physiological inputsdisappear. As long as the monitoring is continuous, one can be sure thatthe patient is the same. While another networked device can perform thisfunction, when the network connection is temporarily lost, only thepatient's own monitor can ensure that the monitoring has continueduninterrupted.

When the patient context includes location, the patient can be locatedin the event he needs to be found, which could be due to various reasonsincluding a fall, loss of communication, patient pressing the nurse-callbutton, or physiological alarm. Patient context can be built using alocation tag that is separate from the patient monitor, but then thelink of asset tag to patient must be made manually.

Implementing the location feature requires that a binding between thelocation tag and the remaining components of the patient context ismade. As mentioned above, this binding can be done automatically andaccurately when the location tag is permanently affixed to or part ofthe patient monitor.

The location solution is typically comprised of a location engine,location sensors (APs in the case of 802.11-based location), and thelocation or asset tags. Location sensors are mapped onto the coordinatesystem of the location engine and the location of asset tags is mappedto this same coordinate system. The location engine populates adatabase, consisting of at least X,Y coordinates and the identifier forthe asset tag. Often, additional information including time and heightand meta information such as the asset type is included in the database.

When a patient monitor indicates the patient to whom it is bound needsassistance, the monitoring server queries the database (either by sharedaccess or an API to the location engine) for the location of the boundasset tag. The coordinates are translated, as necessary to map from thelocation server's coordinate system to the monitoring server'scoordinate system. The monitoring server can then provide audio, text,and or graphical indications that the patient is in need of assistanceand where the patient is located. These indicators could occur on a PC,a PDA, cellular phone, hallway message panel, or other signaling device.For example, a map of the hospital could indicate a flashing red heartat the location of the patient, the patient waveform window can indicate“Arrhythmia, Room 214,” and an audio circuit could annunciate,“Arrhythmia, Room 214”.

Additionally, annunciators can be activated when a clinician needs tofind a patient, as when it is time for a lab. Graphic annunciators canbe active at all times, or only activated upon an event occurring.

Power Modes

Support for multiple power modes can address the differing needs ofmedical devices in the healthcare environment. This includes use modelsfor Continuous Vital Signs monitoring, Spot Check monitoring, and otherclinical devices in need of network connectivity, such as InfusionPumps. These power modes can provide a seamless transition on and offthe network in support of lower power operation or stand aloneoperation, and are fully integrated with the Asset Tracking and LocationService capabilities provided by the MDWA. The preferred embodiment ofthe MDWA supports a selection of at least five distinct PowerConsumption Modes when power is applied to the card. In addition, asixth state of Primary Power Off (no power applied to the main powerconnector) provides a limited functionality of the Location Servicethrough the backup power source 4023. The MDWA power modes are shown inthe power mode state transition diagram of FIG. 3.

When first powered up, the MDWA transitions to Idle mode onceinitialization is complete. Unlike traditional cards, this allows thedevice to be placed in a low power state, remain there as long asneeded, and be ready to transmit a radio packet in a fraction of asecond after the command is given to transition to an active mode.Existing radio cards drop association when changing power modes,resulting in a loss of network connection. In contrast, the MDWA iscapable of transitioning between the first two modes, Continuously Awareand Power Save Polling (PSP), by API control without loss of associationwith an Access Point. Further, the PSP sub-mode can be changed by APTcontrol without loss of association. The MDWA is able to transitionbetween the two active transmission modes (Continuously Aware and PowerSave Polling) and Idle mode by API control. The MDWA is also able totransition from any of these first three modes to Standby or Hibernatemode by API control, and it can further transition from Standby orHibernate mode to Idle mode by toggling one of the control or data lineson the active host interface (e.g., PCMCIA, or Serial Port, or USBinterface). This transition based on external input allows the MDWA tostay in Hibernate or Standby mode for extended periods with outactivating the CPU, thereby saving energy.

In the preferred embodiment, in the Continuously Aware Mode, thetransceiver is either continuously on, or wakes up at least once perbeacon interval in addition to waking to transmit data as soon as it isreceived from the host. This mode is typically used for short periods oftime when the Network Host or Host Device have large amounts of data totransfer and/or many commands to process. The Location capabilities canbe fully operational in this mode, with either high or low resolution.Lower resolution saves power by either transmitting at an increasedinterval, lower power level or using only one of the physicalinterfaces, e.g. RF and not IR.

The Power Save Polling Mode of a preferred embodiment allows the Host tocontrol a requested PSP mode (PSP-n) over the Host Interface. Forexample, in PSP-10 mode, the MDWA awakens every ten intervals,approximately once per second. The transceiver could awaken to transmitdata received from the host immediately upon receipt of the data, but tosave power preferentially synchronizes the data transmission with analready scheduled beacon awakening. This function is either builtdirectly into the MAC layer, which buffers data until a beacon occurs,or the host waits until it is notified that the radio is awakened andthen immediately pushes the data to be transmitted to the radio. TheLocation capabilities can be fully operational in this mode, with eitherhigh or low resolution.

In a preferred embodiment including an Idle Mode, the MDWA's CPU can beready with the radio is turned off. In this mode, the Host Device isable to issue commands, change configuration parameters, and receivestatus over the Host Interface. The Location capabilities can be fullyoperational in this mode, with either high or low resolution. Thecapability of booting to Idle mode enables the boot process of the MDWAto take place in parallel with the boot process of the Host Device. Oncestarted, the Host Device can place the card in any of the alternativemodes. Alternately, the MDWA can boot to any power mode.

A Standby mode is intended to support applications with a use modelindicating intermittent network connection. Here, wireless connectivitycan be turned off until it is time to upload a dataset, and this modesupports a faster time to establish a network connection as compared tothe Hibernate mode. In the preferred embodiment of the Standby mode, theCPU will be “asleep” and the radio will be turned off. The CPU will“wake up” upon the reception of Host API Proxy data on one of the hostinterfaces. The last known AP and channel are retained, precluding inmany events the need to search for an appropriate AP. The Locationcapabilities are fully operational in this mode, with either high or lowresolution.

The Hibernate mode supports applications where the radio has beendisabled for a relatively long time, but still can benefit from a fastnetwork connection time. This mode uses almost no power and allows thehost to effectively turn off the radio, while providing a faster networkassociation time than is possible when leaving Power Off Mode. In apreferred embodiment, the CPU and the radio are turned off and the lastknown AP and channel are retained. The Location capabilities may befully operational in this mode, with either high or low resolution.Because of the extremely small power consumption in the Hibernate mode,instruments make use of the Hibernate mode in multiple situations,including when the user-accessible soft power switch is “turned off” andwhen the instrument needs to operate in a reduced functionality mode dueto depletion of the battery. A low-power hibernate circuit 4016re-powers the Application CPU 4001 to exit hibernate mode.

In one embodiment, the MDWA includes an internal latch in order to keeptrack of whether the Power-On Self Test (POST) has completedsuccessfully. Once the POST has completed (i.e., due to a power-onreset), it is skipped on subsequent transitions out of Hibernate mode.

In a further embodiment, a backup power input 4023 can provide power fora Real Time Location Module when no power is applied to the main powerinput (Power Off Mode). In a preferred embodiment, the loss of powerfrom the main supply causes the Location Module to transition to a lowerpower mode.

Persistent Data

The MDWA can also store persistent data across power off/on cycles andrebooting such as its authentication state, which radio band is in use,e.g., 802.11a or 802.11g, ESSID, power mode, IP address, MAC address,calibration factors, and current AP, regardless of the selected powermode. Storing these data allows the MDWA to reboot and initialize fasterthan depending on an external source to provide the data. It alsoprovides a method to often avoid the time lost to scan channels to findan available AP.

Changing Power Modes

While a typical application running on a PC shows no ill effect due tothe radio card resetting when the radio card operation mode is changed,alarm data and streaming data may be lost during an MDWA reset. To avoidlosing data in these events, in power modes where the CPU is awake, theMDWA can apply configuration changes dynamically without a reset.

Network Protocol Delegation

All network protocols required for communication, authentication, andnetwork management can be encapsulated by the MDWA. A full TCP/IP Stackis also provided by the MDWA, and is exposed to the Host Device througha Host API Proxy for Host APT Mode, and through a bridge application forthe Adapter Mode. A proxied TCP/IP stack on the WMDA avoids the need fora TCP/IP stack on the Host Device, in order to communicate with wirelessor wired Ethernet, further reducing the complexity and resourcerequirements imposed upon the Host Device.

The MDWA can include Port Based Authentication (802.1x), WirelessEncryption (802.11i/ABS and WPA/TKIP), Quality of Service (802.11e),DHCP, NTP, SNMP, and other network protocols familiar to those skilledin the art. We note that the MDWA can be upgradeable to support newnetworking standards and protocols as they are developed. Note thatthese delegations are useful for any embedded host, not simply a medicaldevice.

Bi-directional Authentication

One embodiment of the present invention includes bi-directionalauthentication of the Host Device and the healthcare infrastructureusing Certificates, which protects both the device and theinfrastructure from adversaries. Certificate Management and Processingcan be completely encapsulated by the MDWA. In one embodiment, there canbe provided a minimum of two certificates: “OEM” and “Customer”. The802.1x authentication protocol supports this functionality for bothwireless and hardwired Ethernet, allowing a single authenticationmechanism to be used with either of these external interfaces.

An OEM certificate can provide “Out of Box” device operation with systemproducts that have the matching server-side certificate, such as anAcuity Central Monitoring Station available from Welch Allyn, Inc.,connection server, or other device based on a trust relationshipestablished with the medical device manufacturer. The Customercertificate enables those customers that wish to manage their owncertificate hierarchy to do so, without disturbing the OEM certificatethat can still be used to enable service support and software updates.

Multiple authentication types and certificates can be supported by theMDWA. The MDWA has a selection algorithm that call present the mostlikely certificate to be accepted based on past history or aconfiguration setting. If the most likely certificate is rejected, thealgorithm can then present a second-most likely certificate, and so on.In many clinical contexts internet access is not available, thus withthe device the full certificate chain for the server is installed,supporting bi-directional authentication, independent of externalresources. A MDWA can provide a full interface to manage certificatesand passwords.

Overview of Digital Certificates

Digital Certificates are the foundation of secure authentication for802.11 a/b/g Medical Devices and Infrastructures. Certificates provide ameans of bidirectional authentication that is vastly more secure thancommonly used “secrets” such as usernames and passwords, while at thesame tine avoiding the need for a clinician to enter any information atthe medical device.

A digital certificate binds the identity of a person or device (theDistinguished Name) with a Public Key. This enables bidirectionalauthentication, which protects both the infrastructure from roguedevices, as well as the devices from rogue infrastructures.

Each digital certificate has a corresponding Private Key that is held bythe device that the certificate represents, and is used as part of theprocess to prove the identity of that device. Digital certificates canbe freely distributed, but the corresponding Private Key must be storedin a secure manner by the device, or the security is compromised.

A digital certificate is signed by a Certificate Authority (CA). EachCertificate Authority also has a digital certificate which is signed byanother CA. This process repeats until a “root” CA is reached. A root CAis a CA that signs its own certificate. As a result, every certificate(except for the root CA certificate) has a chain of CA certificatesassociated with it. This chain of trust, provided by the Public KeyInfrastructure (PKI), is what allows a web browser to trace theauthenticity of a web site all the way back to a well known authoritysuch as VeriSign without any intervention by the user.

Medical Grade Wireless Infrastructure

When a World Wide Web user connects to a web site on the Internet, avast number of services provided by the Internet are available. Theseservices include Domain Name Service (DNS), which translates easy toremember domain names into numeric IP addresses, as well as all the PKIsites and services necessary to verify the chain of trust provided bydigital certificates.

However, most wireless infrastructures in the hospital are heavily oreven completely isolated from the Internet. These networks must functionrobustly in this much more isolated and independent environment. Where acertificate for a web site associates the web site name (translated byDNS) with a company name (recognized by the Certificate Authority),these same services need to be provided by the wireless systemcomponents if they are to be used in a virtually isolated Medical GradeWireless Infrastructure.

The IEEE standard 802.11i, commonly referred to as WPA and WPA2,provides a framework for authenticating wireless devices usingcertificates and other mechanisms such as shared secret keys. Thisframework includes the concept of a Radius Server, which supports avariety of authentication methods) and keeps a database of the keys andcertificates that are recognized by the administrators of a given site.A wireless device attempting to access the network encapsulates anauthentication request to the Radius Server in a protocol calledExtensible Authentication Protocol (EAP).

Authentication mechanisms supported by Devices and the Radius Server areknown by their “EAP types”. Of particular interest to a Medical GradeWireless Infrastructure are the three EAP types that supportbidirectional authentication for both the infrastructure and client(device) sides using certificates. These are: EAP-TLS, EAP-PEAP, andEAP-TTLS.

In addition, the MDWA also supports legacy authentication mechanismssuch as Pre-Shared Key (PSK) and WEP with long and short keys.

Device Certificates

Medical Devices that contain the MDWA use certificates to authenticatethe device to the Wireless Infrastructure. The MDWA stores and uses twodistinct certificates for authenticating the device, the “OEM”Certificate, and the “Customer” Certificate. In addition, there is athird certificate installed on the device by the manufacture which isused by the Web Server to set up an encrypted link with a Web Browser.

Device OEM Certificate

The OEM Certificate is installed by the manufacturer of the completedhost Device and one-time installation of the matching server sidecertificate on the end-user's Radius server is required.

On the server-side, use of the Device OEM certificate provides “Out ofBox” operation of all the MDWA-equipped Host Devices with no siteconfiguration of the Host Device.

Device Customer Certificate

Some sites may wish to manage their own certificate hierarchy. Thesecustomers can accomplish this by installing a Customer Certificate onthe Host Device that contains the MDWA, rather than using the OEMCertificate provided by the manufacturer.

If a Customer Certificate is installed, then authentication will beattempted with both the Customer Certificate and the OEM Certificate.The reason for attempting to use both is that a customer could easilylock themselves and the manufacturer out of a device if only theCustomer Certificate were to be used. Customer sites that deploy theirown certificates do not need to install the OEM Server side Certificateson their infrastructure, so only the Customer Certificate willauthenticate successfully. The last certificate to successfullyauthenticate will be marked internally on the MDWA and tried first onsubsequent authentications. This avoids any performance penaltyassociated with trying to authenticate using two different certificates.

Web Server Certificate

A third certificate installed on the device by the manufacture is usedby the Web Server. This Web Server is used for configuring and managingupdates to the Wireless Card.

The Web Server Certificate and its corresponding private key are kept onthe MDWA. These are used to authenticate the MDWA to a Web Browser thatis accessing the administration interface on the MDWA. This certificateand associated private key are also used as seed information to set upthe Secure Socket Layer (SSL) connection between the MDWA and the WebBrowser.

Device Certificate Chains

Since the MDWA might not have access to any Certificate Authority on theInternet during authentication, it must store the entire certificatechain used to verify the Wireless Infrastructure's certificate. The MDWAsupports two distinct certificate chains for authenticating theinfrastructure, the “OEM” Chain, and the “Customer” Chain. There willnormally be multiple certificates in each of these certificate chains.

Server Certificates and Chains

The 802.11 Authentication Server Certificate and its correspondingprivate key are kept on the 802.1x authentication server. Thiscertificate is used to authenticate the Wireless Infrastructure to theMDWA. The Certificate Authority (CA) certificate chain is used to signand validate the various certificates.

Provisioning of Certificates and Certificate Chains

The OEM certificate chain is written to the flash memory on the MDWAduring the provisioning process. When the MDWA boots, it checks if thisarea has new data. If so, the area in flash memory is copied orconverted to a format that can be used directly by the supplicant. Allthe certificates in the certificate chain are concatenated into a singlePEM format file with the root certificate at the beginning of the file.

During the provisioning process, a device certificate and private key iswritten to an area in the flash memory. Like the OEM chain, this OEMdevice certificate and private key are converted into a form (PKCS #12)that can be used directly by the supplicant. The encryption key for thePKCS #12 envelope is also written to flash and converted to a form thatis useable by the supplicant. The MDWA software uses this key to decryptthe PKCS #12 envelope and extract the private key.

Contents and Format of the Device Certificates

The device certificate contains the MAC address in the Canonical Name(CN) section of the certificate.

The device certificate and corresponding private key are generatedoutside the MDWA during the provisioning process. The device certificateis signed by a self signed or traceable Certificate Authority. Then thedevice certificate and private key are packaged into an encrypted PKCS#12 envelope. The OEM device certificate and key are installed on theMDWA at provisioning time. If the customer wishes to install their owndevice certificate and key, the PKCS #12 envelope and the password todecrypt it will be uploaded to the MDWA through the web administrationinterface.

Committed Bandwidth

Many medical devices use a dedicated and/or proprietary network as amethod to provide dedicated bandwidth, resulting in a high probabilityof packet transmission success. Each dedicated/proprietary network addscost for the hospital, A preferred implementation is that the manymedical devices can share a single network. Experience with the WMTSexperiment for the last 7 years indicates that competing manufacturersare not capable of creating solutions that work together in the absenceof a standard. However, for the network to be shared, both the networkand the clients that require a committed bandwidth on the network mustsupport the same method for allocating and sharing bandwidth. Bandwidthallocation and prioritization such as that provided by the 802.11e QoSstandard can support and enable a pre-allocation of a committedbandwidth in support of the real-time vital signs data (and other highpriority data), so that other applications that share the infrastructurecan do so without adversely impacting applications such as vital signsmonitoring and alarm reporting. Further, a method for ensuring that thebandwidth is available includes testing the network against the intendeduse, including all planned network loads. This can be accomplished atinstallation time using tools such as IxChariot, available from Ixia.

SAR Management (FCC Low Power Exemption)

The FCC limits the amount of Joule heating by a transmitter on portabledevice (portable devices are defined as those used within 20 cm of thebody) averaged over any 6-minute time interval. A typical 802.11 radioexceeds the SAR limits for a patient worn device unless the EIRP(Effective isotropic radiated power; EIRP=Power*Antenna_Gain) is verylow. In this case, the transmission distance is severely limited.However, when the transmission protocol restricts the transmit dutycycle, source based averaging can be used. Assuming the transmissionprotocol limits the duty cycle to 10 percent, then a factor of 0.10 isapplied to the SAR level, allowing the radio to have a high EIRP whenthe transmission occurs, resulting in an improved transmission range. Todo this, the radio must provide a measure of the transmission dutycycle. Coupled with a knowledge of the antenna gain and transmit power,this allows the MDWA or Host Device (when the information is sent acrossthe Host API) to implement a protocol that enforces a limit on the SAR.This limit provides support for either meeting the FCC SAR low-powerexemption, or simply staying below the SAR limits.

Watch Dog

MDWA failure reports include failures due to latch up, including failureof microprocessor internal watch dog timers. Typical off the shelfradios may latch up and stop transmitting, with no way to alert the hostdevice, resulting in loss of ability to transmit patient alarms. Shoulda software application or operating system fault occur, the MDWAincorporates an independent watch dog circuit, external to themicroprocessor, which provides a means to restart the module, whereuponthe MDWA alerts the host device of the reboot via the Host API, andreturns the MDWA to a known state.

POST and BIST

One embodiment of the MDWA contains a Power-On Self Test (POST) and aBuilt-In Self Test (BIST). The POST occurs when the module is firstpowered up to ensure that the major functions operate correctly, but isbypassed during subsequent transitions out of hibernate mode (where theCPU was powered down), decreasing the power-up time. The BIST canprovide a much more extensive set of tests and diagnostics, and may beused both during manufacturing as well as at the customer site to verifycorrect operation of the module and diagnose any hardware failure.Typical radio cards either report nothing upon start up or a numericalerror code that call not be interpreted by the host. The BIST and POSTprovide diagnostics that are not typically available to the host device.

Software Updates

A MDWA can support updates of the wireless adapter software from thewireless network interface with little or no involvement by the HostDevice. The MDWA can automatically download and install the newfirmware. Alternately, devices with a user interface and appropriateservice screen may trigger the final SW load into the MDWA through thatuser interface. In another implementation, the MDWA can be designed toload SW from the Network Server on power up or boot or upon other event(such as notification across the Host API) where the MDWA can be sure nopatient is being monitored. Enterprise solutions can be used to have anexternal server push new firmware to the MDWA.

In one embodiment, the MDWA provides the ability for the Network Serverto program the card software. By way of example, there are three methodsfor providing software updates. In the first method, the deviceoverwrites its own firmware in real-time, which poses problems if thereis an error in the code load. In a second method, two copies of thefirmware can be stored on the device and the power up interrupt canpoint to either copy. Upon boot failure of a newly loaded version, theboot core can re-boot from the earlier firmware version. The thirdsolution is a compromise between the first two methods, where the newfirmware overwrites most, but not all of the original firmware. The bootcore, responsible for a few basic operations, including writing newfirmware, is left unchanged. In the event the firmware load is corrupt,the boot core is still available to re-load firmware. The secondsolution requires and the third solution can use a separate bank ofmemory from that location where code is run. This allows new firmware tobe downloaded and the code integrity confirmed before the new firmwareis executed. Integrity checks include CRC and revision checks.

The ability to update the MDWA software through the radio interface canallow a network product to update all of the MDWAs on the network,independent of the instrument type or protocol. In one embodiment,updates of the wireless card software are made over the wireless networkinterface with little or no involvement by the host device. The MDWAsoftware can be supplied by HTTP, FTP, TFTP, SNMP, and other servicesknown to those skilled in the art. The independence of softwarerevisions to instrument type or protocol reduces the complexity of thehost device software that needs to be integrated into each instrumentand validated.

Typically, anyone with the programming tool can upload new firmware tothe card. The preferred embodiment, however, advantageously usesbi-directional authentication to ensure that no one can “hijack” thedevice and install

While MDWA firmware updates can be accomplished in a device independentmanner in one embodiment, in the preferred embodiment, device firmwareupdates will benefit from some support from the Host Device andassociated communications protocol. This protocol allows a confirmationthat no critical applications, e.g. continuous vital signs monitors inprocess, will be interrupted by a MDWA firmware update.

By way of example, for an MDWA embedded in a monitor, firmware updatesof the MDWA can be done by either: (a) disassembly of the monitor, (b)loading the MDWA firmware into the monitor, which subsequentlyre-programs the MDWA or (c) an over-the-air update. Option (a) requiresexcessive work for each firmware update and option (b) requires customfirmware be written on both the MDWA and Host Device sides. Both requirephysical access to the Host Device. For these reasons, the preferredembodiment performs firmware updates for the MDWA over a WLANcommunications interface. Further, since medical devices are regulatedand must have traceability of all device software by serial number, theMDWA can provide the capability to store and export version informationfor Host Device hardware and software components to the network system.This version information can in turn be used by the system software todetermine what software modules or releases are appropriate for theMDWA, the Host Device, and each of the sub-components that make up theHost Device.

In a further embodiment, the MDWA provides a software update to a HostDevice by loading new Host Device software, including firmware updatesas part of the Host API, from the wireless network. This allows the HostDevice to use the MDWA as a staging area for loading firmware updates.That is, the memory that supports firmware upgrades for the MDWA canalso be used as a staging area for over-the-air firmware upgrades. Theinvention includes a Host API that allows the Host Device to use MDWA'smemory via any host interface.

Medical device operation cannot be safely interrupted; therefore in oneembodiment, the MDWA provides a mechanism via the Host API Proxy and/orinspection of data using Adapter Mode that restricts firmware upgradeactivity to only occur when there is no patient activity.

Diversity

Diversity is typically used on reception where the received power ofdifferent antenna elements is analyzed, and the element with the highestpower is used for RF input. The different antenna elements can easilyhave a 30 dB performance difference, depending on theconstructive/destructive interference at that point in space. Thishighest power element is assumed to be the best element fortransmissions that occur at a time very close to the reception. The MDWAsupports one or more antennas, any of which may be disabled for HostDevices that cannot accommodate a second antenna. By way of example,antennas can be oriented to provide polarization and spatial diversityfor both the 2.4 and 5 GHz bands. The use of diversity can also bemanipulated by the system software, so that the performance of the802.11 location capabilities can be improved by sending some packetsthrough both antennas, improving the radiation profile to achieve a moreisotropic pattern and thus better accuracy for determining the locationfor systems that use received RF power as an input variable for locationdetermination. A cabled, modular antenna allows for easy disposition ofthe antenna within an embedded device. In comparison, an antenna that isfixed with respect to the MDWA may be too large in one dimension forinclusion in the host device. A cabled antenna also can allow for anantenna-radio pair with a modular device approval to fit inside multipleembedded devices, where a fixed antenna would not, simplifyingregulatory and compliance efforts for the host device development.

In the case where the location beacons are transmitted without any RFreception, it is not obvious which element should be used. In this case,one embodiment of the MDWA system splits power between the two elements,possibly producing a circularly polarized signal. If location beaconsare very short and transmitting two beacons, one out each antenna thenas in a preferred embodiment, then the beacon is transmitted via antenna1 and then via antenna 2.

Alternate Channel

Some Real Time Location Services (RTLS) (including location productsthat can provide a secondary communication system, such as the AeroScoutand Radianse systems) can provide a telemetry channel, typicallysupporting only a small data payload. The MDWA supports such interfacesand can use such systems as an auxiliary telemetry channel. For example,this channel can either be used at all times, enabled as a function ofthe host's state, or enabled as a function of the 802.11 link state. Thedata payload can be any state information for the Host Device,including, but not limited to, patient alarm status, a reduced set ofphysiological data, performance metrics, battery status, host on/off,802.11 link status, etc.

Mesh Network (Gateway)

The MDWA provides a mesh network capability by acting as a client on onenetwork or channel, an Access Point (AP) on another network or channel,and routing packets between those networks. For example, the MDWA can bean AP on a first network, such as a low power personal area network(PAN), and a station (STA) on a second network, such as an 802.11a/b/gnetwork. The MDWA can route packets between these two networks. Thesenetworks could use the same or completely different protocols, includingbut not limited to 802.11a/b/g, a Personal Area Network including any ofthe IEEE standards, e.g. 802.15.1 (BlueTooth), 802.15.3 (UltraWideband), 802.15.4 (Zigbee), a Metropolitan Area Network such as 802.16(WiMAX) or HiperMAN, and Wide Area Networks, including cellular. Usingone or more of these various types of networks, the MDWA call aggregatevital signs data from one or more sensors directly attached to or wornby the patient, or from one or more applications running on the Wirelessadaptor, or a combination thereof. The MDWA can further process thatdata (or aggregated data) in order to suppress false alarms. Once thedata has been processed, the device can then forward the processed andfiltered information to another device, e.g. server, PDA, laptop,cellular phone, connected to the wireless infrastructure. We note thatfor some networks, the concept of routing in the IP sense is notdefined. For these networks, the MDWA implements the analogousfunctionality of taking data to/from devices on a first network andappropriately formatting the data from/to a second network.

Additional Functions

Several of the MDWA 100 functions are now described in more detail. Inone embodiment, the MDWA provides two modes of operation. In eithermode, the device can be customized to meet the needs of the Host Deviceand the final application. Parameters can be configured as follows:

The MDWA first provides a method to set modes for default operation,including selection of which host interface to use (USB, Serial, PCMCIA,Ethernet, Card Bus or other interface known to those skilled in the art)and defining the protocol variables, e.g. bit rate, flow control on/off.The host interface to use can be determined automatically, or set once.In another embodiment, auto rate detection algorithms are implemented inaddition to setting a default operation mode.

The MDWA further provides a method to set TCP/IP and 802.11 parameters,e.g. configuring for DHCP or Static IP address assignment, and ServiceSet IDentifiers (SSID).

The MDWA further provides a method to install network applications, suchas a web server/client, TFTP server/client, FTP Server/Client, SNMPclient, NTP client, 802.1x supplicant, and other network applicationsfamiliar to those skilled in the art. These applications provideservices for the radio card which the host inherits without having toimplement each of these services on the host itself. For Host Deviceswith memory, CPU, and other constraints, this provides substantialsavings.

In one embodiment, a TFTP client is directed to download new firmwarefor the MDWA and/or the host from a server. A TFTP server is then usedto upload the firmware from the MDWA to the host. As those skilled inthe art are aware, the same can be accomplished with a webserver/client, through FTP, SNMP, and other applications. In addition,an NTP client provides a way for the host to always have an accuratedate and time. This is important for time-stamping data and/ordebugging, where accurate time stamps allow temporal correlation of datafrom the client with data from the network.

The MDWA further provides a method to install supplemental applicationsthat increase the functionality of the MDWA to that similar to aconventional medical device. These functions include, but are notlimited to, the ability to process, partially process, or aggregate dataincluding, ECG data (including arrhythmia detection); EEG data; S_(P)O₂data; CO₂ data; cardiac output data; and temperature data. In oneembodiment, partial processing of data can be used to off-load from theHost Device algorithms for which the Host Device does not havesufficient CPU bandwidth.

In one embodiment, the aggregation of data feature can be used whenmultiple sensors on various networks are attached to the same patient,for example, when a stand-alone S_(P)O₂ monitor and a stand-alone ECGmonitor are used. In this case, knowledge of both data sets allows amore robust interpretation of the patient's condition. Arrhythmiaanalysis can be augmented by knowledge of the oxygen saturation levelsand the trends thereof. For example, a drop in oxygen saturation levelswhile the heart continues beating normally could indicate a pulmonaryproblem such as apnea or airway obstruction.

The MDWA further provides a method to configure security parameters.Such parameters include, but are not limited to, installingcertificates, setting passwords, and other security configurationsettings known to those skilled in the art. Other parameters relate toinstalling a serial number, and MAC address, applying firmware upgrades,defining the operating parameters for location beacons, and in the caseof adapter mode, configuring a discovery protocol.

Diagnosis

Another aspect of the MDWA involves debugging and diagnosis of an MDWAand/or host device or host device APT in the field. For example, aremote technical service group could do such debugging if statusinformation is made available over the medical network. A MDWA accordingto the invention can provide status information including radioperformance metrics such as RSSI, retry rates, channel information,Signal-to-noise ratio and version information to a host computer. Suchinformation can be sent over a network via SNMP or other methods knownto those skilled in the art. A further embodiment of the MDWA includesfunctionality to support remote trouble shooting and problem resolutionthrough both interactive and automated diagnostics, such as reportingthe results of self tests, of hardware/software compatibility status aswell as the results of upgrades and configuration changes. Moreover, theMDWA can provide support for a function to partially or completelyrestore a factory default configuration.

Roaming

Roaming is defined herein as a circumstance where a device orinstallation including a MDWA logically changes association status fromone AP to another, typically due to physically moving from one locationto another, but also due to noise levels, AP loading, and other factorsthat may make a second AP provide a better communication channel. In oneembodiment, the MDWA can support a roaming velocity of at least 5 milesper hour, even with encryption and authentication enabled.(Authentication adds an additional step to the roaming process.) ThisMDWA can further periodically scan for available Access Points in orderto maintain a list of neighboring APs, which allows the MDWA to quicklyjump to a new AP in the event the current AP becomes unavailable. TheMDWA can use other solutions, such as CCX V2 or greater (Ciscocompatibility extensions) or 802.11r in order to populate the AP list.In some applications when a device including a MDWA is out of range, areduced scan interval can be applied after a timeout in order to reducepower consumption. The reduced power feature can be configured to runautomatically or to be set through a Host Interface API.

Additional Uses

Additional embodiments of the MDWA include web servers, enabling MDWAuse as: (a) a universal device configurator; (b) virtual display; (c) abroadcasting device for data display on a large screen monitor in theprocedure or patient room; (d) a universal device upgrade utility; and(e) as an application server.

In one embodiment, a MDWA can include a web server for use as auniversal device configurator. Using the MDWA universal deviceconfigurator, medical devices can be configured or re-configuredremotely or locally over the internet. Such remote configuration cansimplify the proliferation of device configurator applications and theconfiguration processes.

Additionally, a web server is installed on the WMDA to provide a virtualdisplay of the host device that can be viewed via a web browser. TheMDWA application can format and broadcast device data for display on alarge screen monitor, such as a Monetron sold by Welch Allyn, Inc. AMonetron is a large screen that is used to collect patient monitor dataand display it locally (in the same manner that a central monitoringstation might see the data) to enable consulting physicians to see thedata. This MDWA embodiment is also enabled to collect and combine datafrom other sources (devices, EMR) and broadcast for display on a largescreen monitor (such as Monetron).

In a further embodiment, a web server is installed on the MDWA to enablethe MDWA's use as universal device upgrade utility. The small web serverallows a customer and/or service technician to connect to a secureserver via a browser and to download and install updated firmware.

In a further embodiment, the web server on the MDWA allows for acustomer to license new parameter analysis software that extends thecapabilities of the device, and thus the MDWA functions as anapplication server. The new software can run on the MDWA instead of thedevice processor. The MDWA application displays the new hybrid data in abrowser on a device having a suitable display, or the MDWA can send thedisplays by wireless connection to a remote monitor, including a largescreen monitor.

While the invention has been described with reference to particularembodiments, it will be understood by those skilled in the art thatvarious changes may be made and equivalents may be substituted forelements thereof without departing from the scope of the invention. Inaddition, many modifications may be made to adapt a particular situationor material to the teachings of the invention without departing from thescope of the invention. Therefore, it is intended that the invention notbe limited to the particular embodiments disclosed as the best modecontemplated for carrying out this invention, but that the inventionwill include all embodiments falling within the scope and spirit of theappended claims.

1. A medical device wireless adapter comprising: a radio section; one ormore means for connecting to and exchanging data between said adapterand a host device; one or more means for exchanging data between saidadapter and a network; a CPU block including integrated support forhosting one or more applications; and one or more memory means; whereinsaid adapter is configured with one or more host interface modes.
 2. Theadapter of claim 1, wherein said adapter is a PCMCIA card.
 3. Theadapter of claim 1, wherein said means for connecting to and exchangingdata with a host device is a PCMCIA bus.
 4. The adapter of claim 1,wherein said adapter is a module.
 5. The adapter of claim 1, whereinsaid adapter is a card.
 6. The adapter of claim 1, wherein said adapteris a plug-in device.
 7. The adapter of claim 1, wherein said means forconnecting to and exchanging data with a host device is one or moreserial ports.
 8. The adapter of claim 1, wherein said means forconnecting to and exchanging data with a host device is one or moreEthernet ports.
 9. The adapter of claim 1, wherein said means forconnecting to and exchanging data with a host device is one or more USBports.
 10. The adapter of claim 1, wherein said adapter furthercomprises a manufacturing interface.
 11. The adapter of claim 10,wherein said manufacturing interface is adapted to program said CPU andsaid at least one memory with firmware.
 12. The adapter of claim 1,wherein said adapter further comprises a de-bugging block.
 13. Theadapter of claim 12, wherein said de-bugging block is adapted to performself test routines.
 14. The adapter of claim 1, wherein said radiosection includes a MAC-baseband processor and a radio frequencytransceiver.
 15. The adapter of claim 14, wherein said radio sectionfurther includes a WiFi RF chip set.
 16. The adapter of claim 1, whereinsaid radio section is connectable to said CPU block by a CPU compactflash bus.
 17. The adapter of claim 1, further comprising one or moreantennas.
 18. The adapter of claim 17, wherein said one or more antennasis a WiFi antenna.
 19. The adapter of claim 18, wherein said WiFiantenna is connectable to said radio section by a pigtail and connector.20. The adapter of claim 17, wherein said one or more antennas arearranged in a dual diversity antenna configuration.
 21. The adapter ofclaim 1, wherein said adapter is a 802.11 a/b/g network interface card.22. The adapter of claim 1, wherein said adapter further comprises atleast one user interface.
 23. The adapter of claim 1, wherein saidadapter includes one or more configuring means, wherein said configuringmeans is chosen from the group consisting of: setting TCP/IP parameters;adding applications; removing applications; for installing securitycertificates; removing security certificates; setting one or morepasswords; setting a default operation mode; setting a serial number;setting a MAC address; upgrading firmware; setting a rate oftransmission for one or more location beacons; setting hostconfiguration parameters; configuring a discovery protocol; configuringauthentication; and configuring encryption.
 24. The adapter of claim 23,wherein said host configuration parameters are chosen from the groupconsisting of bit rate and flow control.
 25. The adapter of claim 1,wherein said adapter includes a means for connecting to anauthenticated, encrypted network.
 26. The adapter of claim 1, furthercomprising one or more interfaces, wherein at least one of said one ormore interfaces is a host interface.
 27. The adapter of claim 26,wherein said adapter includes a means for automatically determining oneor more active host interfaces.
 28. The adapter of claim 1, wherein saidadapter includes one or more location tracking modes and one or morebeacons.
 29. The adapter of claim 28, wherein said one or more locationtracking modes is operational as a function of a host device's powerstate.
 30. The adapter of claim 29, wherein said power state is chosenfrom the group consisting of power off, low battery, battery removed,and low-power mode.
 31. The adapter of claim 28, wherein said one ormore beacons is an integrated multiple physical layer location beacon.32. The adapter of claim 31, wherein said integrated multiple physicallayer location beacon includes a variable rate.
 33. The adapter of claim31, wherein said adapter is configured to utilize a subset of saidintegrated multiple physical layers of said location beacon.
 34. Theadapter of claim 29, wherein said beacons are configured to transmitdata at a regular rate.
 35. The adapter of claim 29, wherein saidbeacons are configured to transmit data at a variable rate.
 36. Theadapter of claim 49, wherein said variable rate is a function of a powerstate of said adapter.
 37. The adapter of claim 28 wherein said adapterfurther comprises a dedicated power supply means connected to said oneor more location tracking modes and one or more beacons.
 38. The adapterof claim 1, further comprising a power management block.
 39. The adapterof claim 1 wherein said adapter is configured with one or more powermodes.
 40. The adapter of claim 39 wherein said adapter includes PSP andCAM modes, and is configured to dynamically switch between said PSP andCAM modes without losing network connection.
 41. The adapter of claim 39wherein said one or more power modes are chosen from the groupconsisting of: an idle mode wherein said radio block is turned off andsaid CPU block remains active; a standby mode wherein said radio blockis turned off and a CPU block clock is stopped; and a hibernate modewherein both said radio block and CPU are turned off.
 42. The adapter ofclaim 41 wherein said adapter is configured to store a network state toallow for rapid re-association.
 43. The adapter of claim 42 wherein saidnetwork state is chosen from the group consisting of AP, Channel, and IPAddress.
 44. The adapter of claim 41 wherein said CPU block isconfigured to automatically exit standby mode to a fully functionalstate upon detection of activity on a host interface.
 45. The adapter ofclaim 41 wherein said CPU block is configured to automatically exithibernate mode to a fully functional state upon detection of activity ona host interface.
 46. The adapter of claim 1, wherein said adapterfurther comprises a primary and secondary power supply.
 47. The adapterof claim 28, wherein said one or more beacons operate independent of apower state of the adapter.
 48. The adapter of claim 1, wherein saidadapter is configured to perform a power-on self test.
 49. The adapterof claim 48, wherein said adapter performs said power-on self test onlywhen power to said adapter is cycled.
 50. The adapter of claim 1,wherein said one or more applications is chosen from the groupconsisting of bi-directional authentication; 802.11i encryption; one ormore web servers; a plurality of password/user name combinations; aTCP/IP sockets API proxy; a conversion means from a native devicecommunication protocol to one or more TCP/IP network interfaces; a SNMPserver; a FTP server; and a TFTP server.
 51. The adapter of claim 50,wherein said bi-directional authentication follows the ExtensibleAuthentication Protocol.
 52. The adapter of claim 51, wherein saidExtensible Authentication Protocol follows the 802.1x standards.
 53. Theadapter of claim 50, wherein said bi-directional authenticationapplication is configured to provide certificate management andprocessing.
 54. The adapter of claim 50, wherein said bi-directionalauthentication application is configured to provide password managementand processing.
 55. The adapter of claim 50, wherein said bi-directionalauthentication application is configured to work with multiplecertificates.
 56. The adapter of claim 55, wherein said bi-directionalauthentication application is configured to intelligently choose whichof said multiple certificates to offer a RADIUS server.
 57. The adapterof claim 50, wherein said web server is a secure server.
 58. The adapterof claim 50, wherein at least one of said plurality of password/username combinations is a function of unique identifiers specific to saidadapter.
 59. The adapter of claim 50, wherein said TCP/IP sockets APIproxy is configured to support multiple endpoints.
 60. The adapter ofclaim 50, wherein said TCP/IP sockets API proxy is configured tosimultaneously accept commands and data.
 61. The adapter of claim 50,wherein said TCP/IP sockets API proxy is configured to providedeterministic behavior with respect to command and data traffic.
 62. Theadapter of claim 50, wherein said conversion means from a native devicecommunication protocol to one or more TCP/IP network interfaces providesa means for a non-networked host device to communicate on a networkwithout modifying existing hardware or software.
 63. The adapter ofclaim 50, wherein said conversion means from a native devicecommunication protocol to one or more TCP/IP network interfaces isconfigured to fulfill communications requirements needed to establish acommunication link between a non-networked host device and a networkdevice.
 64. The adapter of claim 63, wherein said requirements arechosen from the group consisting of FTP, TFTP, electronic mail, and aserver.
 65. The adapter of claim 1, wherein said one or moreapplications is chosen from the group consisting of: ECG processing;arrhythmia processing; SPO2 processing; temperature processing; bloodpressure processing; CO2 processing; cardiac output processing; and EEGprocessing.
 66. The adapter of claim 65, wherein said blood pressureprocessing is for non-invasive blood pressure measurement.
 67. Theadapter of claim 65, wherein said blood pressure processing is forinvasive blood pressure measurement.
 68. The adapter of claim 65,wherein said CO2 processing is for End-Tidal CO2.
 69. The device ofclaim 65, wherein said CO2 processing is for sidestream COc 29.3. 70.The adapter of claim 1, wherein said one or more applications includesan integrated bar-code scanner.
 71. The adapter of claim 1, wherein saidradio block contains an NTP client.
 72. The adapter of claim 1, whereinsaid radio block contains at least one watchdog circuit to recover fromlatch up.
 73. The adapter of claim 72, wherein said at least onewatchdog circuit is disposed externally to a microprocessor.
 74. Theadapter of claim 1, wherein said adapter is embedded with bandwidthallocation and control.
 75. The adapter of claim 74, wherein saidbandwidth allocation and control meets 802.11e standards.
 76. Theadapter of claim 1, wherein said adapter further includes a self testcapable of determining full functionality of integrated circuits. 77.The adapter of claim 1, wherein said adapter includes arate-versus-range algorithm, wherein said algorithm has been optimizedfor a high packet success rate.
 78. The adapter of claim 1, wherein saidadapter is configured to provide firmware upgrades to a host device. 79.The adapter of claim 78, wherein firmware upgrades are conditioned uponthe state of said host device not actively monitoring a patient.
 80. Theadapter of claim 78, wherein said adapter further comprises means todetermine whether said host device requires a firmware upgrade.
 81. Theadapter of claim 80, wherein said adapter is configured to provide afirmware upgrade status to a network device.
 82. The adapter of claim78, wherein said adapter further comprises means to download a firmwareupgrade for a host device.
 83. The adapter of claim 1, wherein saidadapter is configurable to aggregate data from said one or moreapplications.
 84. The adapter of claim 1, wherein said adapter isconfigured to act simultaneously as a network master and a networkslave.
 85. The adapter of claim 84, wherein said adapter is configuredto act as a slave on a first network and a master on at least one othernetwork.
 86. The device of claim 85, wherein said adapter is configuredto route packets from said first network to said at least one othernetwork.
 87. The adapter of claim 85, wherein said at least one othernetwork uses a different protocol than the said first network.
 88. Theadapter of claim 83, wherein said adapter aggregates data from multiplesensors disposed across at least one network.
 89. The adapter of claim88, wherein said adapter processes data from said multiple sensors. 90.The adapter of claim 1, further comprising a cabled, modular antenna.91. The adapter of claim 90, wherein said antenna is chosen from thegroup consisting of a diversity antenna and a dual-band antenna.
 92. Theadapter of claim 91, wherein said diversity antenna can be disabled orenabled.
 93. A medical device wireless adapter comprising: a radiosection; a means for connecting to and exchanging data with at least onehost device; at least one means for exchanging data between said adaptorand a network; a CPU block including integrated support for hosting atleast one application; and at least one memory means; wherein said radiosection, said connection means, said CPU block, and said memory meansare disposed on a unitary structure; and wherein said adapter isconfigured with at least one interface mode.
 94. The adapter of claim93, wherein said adapter is a PCMCIA card.
 95. The adapter of claim 93,wherein said means for connecting to and exchanging data with a hostdevice is a PCMCIA bus.
 96. The adapter of claim 93, wherein saidadapter is a module.
 97. The adapter of claim 93, wherein said adapteris a card.
 98. The adapter of claim 93, wherein said adapter is aplug-in device.
 99. A wireless adapter comprising: a radio section; oneor more means for exchanging data between said adapter and a hostdevice; one or more means for exchanging data between said adapter and anetwork; a processing circuit including one or more microprocessors,wherein said one or more microprocessors are configured to host one ormore applications and one or more radio transceivers; and one or morememory means; wherein said adapter is configured with one or more hostinterface modes.
 100. A medical device wireless adapter comprising: aradio section; one or more means for exchanging data between saidadapter and at least one host device; one or more means for exchangingdata between said adapter and a network; a CPU block includingintegrated support for hosting one or more applications; a de-buggingblock; a power management block; a manufacturing interface; a userinterface; and one or more memory means; wherein said adapter isconfigured with one or more host interface modes.
 101. A method foradapting a legacy medical device to a wireless infrastructure,comprising the steps of: providing a legacy medical device; providing amedical device wireless adapter, wherein said adapter comprises a radiosection, one or more means for connecting to and exchanging data betweensaid adapter and said host device, one or more means for exchanging databetween said adapter and a wireless infrastructure, a CPU blockincluding integrated support for hosting one or more applications; andone or more memory means, wherein said adapter is configured with one ormore host interface modes, and wherein one of said one or more hostinterface modes is Adapter Mode; configuring said adapter with a set ofparameters appropriate to said host device, wherein said parameters arechosen from the group consisting of network settings, communication portsettings, and rendezvous packet definition; connecting said adapter tosaid host device; detecting when said host device has requires a networkconnection; presenting said host device to said wireless infrastructurevia said adapter; and enabling a network connection by exchanging databetween said wireless infrastructure and said host device via saidadapter.
 102. The method of claim 101, further comprising the steps ofconfiguring said adapter to execute at least one rendezvous protocol onbehalf of said host device, and executing said protocol.
 103. The methodof claim 102, further comprising the step of broadcasting to saidinfrastructure said protocol, wherein said protocol comprises a UDPpacket of a pre-defined format.
 104. The method of claim 102, furthercomprising the step of passing bidirectional data between said hostdevice and said wireless infrastructure via said adapter once saidrendezvous protocol is executed.
 105. The method of claim 101, whereinsaid network connection is enabled by the further steps of associating,obtaining an IP address, and authenticating.
 106. A method of convertingan 802.11 radio into an asset tag and back to an 802.11 radio,comprising the steps of: providing an 802.11 radio, wherein said radioincludes a radio section, one or more means for connecting to andexchanging data between said radio and a wireless infrastructure, one ormore location tracking modes, and one or more beacons, wherein saidradio includes configurable beacon parameters; configuring said one ormore beacon parameters, wherein said parameters are chosen from thegroup consisting of transmit power, duty cycle, and beacon method;executing a loop until data transaction required, wherein said loopcomprises the further steps of detecting when low-power operation isrequired, booting an operating system, transmitting the beacon asconfigured and sleeping until the next beacon; ending said loop; andbooting a full operating system.
 107. A method for adding location to apatient context comprising the steps of: providing a patient monitor;providing an asset tag, wherein said asset tag includes an identifier;providing a location engine, wherein said location engine includes acoordinate system; providing location sensors; connecting said asset tagto said location engine; determining content of a patient context,wherein said patient context includes at least one identifier unique tosaid patient; binding said asset tag identifier and said at lease oneidentifier unique to said patient; mapping said location sensors to saidcoordinate system; mapping the location of said asset tag to saidcoordinate system; populating a database, wherein said database containsdata chosen from the group consisting of x,y coordinates, asset tagidentifiers, time, height, asset type, and meta information; providingone or more annunciators, wherein said one or more annunciators ischosen from the group consisting of audio, text, and graphic; providingconditions for activating said one or more annunciators; activating saidone or more annunciators; and indicating the location of said patientwhen said conditions for annunciating are satisfied.
 108. The method ofclaim 107, wherein said patient context comprises information chosenfrom the group consisting of: name; patient ID; current state ofphysiological parameters; alarm limits; and location.
 109. The method ofclaim 107 wherein said patient context includes at least one continuousvital sign reading, wherein disruption of said continuous vital signreading breaks said binding between said asset tag identifier and theremainder of the patient context.
 110. A method for supporting out ofbox operation with strong authentication and encryption for a medicaldevice wireless adapter comprising the steps of: providing a medicaldevice wireless adapter, wherein said adapter comprises a radio section,one or more means for connecting to and exchanging data between saidadapter and a host device, one or more means for exchanging data betweensaid adapter and a wireless infrastructure, a CPU block includingintegrated support for hosting one or more applications; and one or morememory means, and wherein said adapter is configured with one or morehost interface modes, an OEM certificate, an OEM certificate chain, aweb server certificate, and a web server certificate chain; determiningif a customer device certificate is required; creating a customer deviceand server certificates if required; creating certificate chains forcustomer certificate; installing customer certificate to provisionradio; installing server certificates to provision said infrastructure;powering-on said device; authenticating, wherein said adapter will loopa process until authentication is complete, wherein said processincludes the further steps of starting loop; attempting to authenticateusing a primary certificate; completing network authentication ifsuccessful; determining if network authentication occurred; promoting asecondary certificate to primary certificate if authentication failed tooccur; and ending loop; and completing the network connection.